1.1 Introduction
This invention relates to a method for improving security in a computer system. More specifically, this invention concerns a method for implementing trusted commands through both trusted and untrusted code.
1.2 Background
The proliferation of computers has resulted in the need for reliable computer security systems. The need to protect certain information is great in areas dealing with national security, for example. Security measures are required in other fields, including areas which utilize financial, medical, and personal information. Many computerized information systems therefore include internal security measures which provide the users with different levels of access to the computerized information, and which attempt to provide at least a degree of protection of the information from undesirable access.
1.3 Security Criteria: Reference Validation Systems
In response to the need for secure computer systems, the Department of Defense has issued a publication titled Department of Defense Trusted Computer System Evaluation Criteria (reference No. DOD 5200.28-STD). This publication is sometimes referred to as the “Orange Book,” and is available from the Department of Defense. The Orange Book describes system security objectives and evaluation criteria for secure computer systems.
A “secure” computer system generally includes some type of “reference validation” system. These reference validation systems (known as reference monitors) are responsible for enforcing the security rules (security policy) for a given computer system.
Reference monitors mediate all access to “objects” by “subjects”. Objects are passive entities that contain or receive information. Access to an object implies access to the information that it contains. Subjects are active entities, generally in the form of a person, process or device that cause information to flow among objects or change the system state. A subject may ordinarily reference its own, subject-internal information without the involvement of the reference monitor. Reference monitors controlling such access to objects by subjects are known in the art, and may utilize a security kernel approach.
Proper implementation of a reference monitor calls for adherence to three principles:                (1) completeness, in that all access by subjects to objects or other subjects must involve the monitor;        (2) isolation, in that the monitor must be protected from tampering; and        (3) verifiability, in that correspondence must be shown between the security policy and the actual implementation of the monitor.        
As discussed, every reference to information or change of authorization should go through the reference monitor. Thus, all commands issued by a user or other subject are monitored by the reference monitor. This approach is particularly useful in multiuser computer environments.
The totality of the protection mechanisms within a computer system—including hardware, software, and firmware, the combination of which is responsible for enforcing a security policy—is commonly known as a “trusted computing base” (TCB). If the trusted software is designed to be as simple as possible, for the sake of verifying the reference monitor, then the trusted software is known as a “security kernel”.
Generally, TCBs attempt to meet the control objectives set out in the Orange Book. Compliance with these objectives inspires user confidence, and increases the overall desirability of a computer system. These objectives deal with:                (1) security policy;        (2) accountability; and        (3) assurance.        
The security policy objective entails enforcement by the TCB of the desired security rules. These security rules are designed to limit the access to and dissemination of information in a precisely defined manner.
Security policies may include provisions for the enforcement of both mandatory and discretionary access control rules. Mandatory access control rules control access based directly on comparisons of the user's security level and the sensitivity level of the information being sought. Discretionary access rules control and limit access to identified individuals who have been determined to have a need-to-know.
These access control rules call for associating with each user identification code a statement indicating the user's access rights. This statement often includes information representing the user's security level (for mandatory control purposes), and membership in groups (for discretionary control purposes).
The accountability objective calls for providing each user with an individual user identification code (often called a “user name”) and for the TCB to be able to recognize the code and ensure that it is being used by its proper user. This may be done by checking the user's password. This ensuring the user's identity is known as “authentication.”
In addition, the accountability requirement calls for the existence of auditing capabilities. Such capabilities allow for the auditing of actions which can cause access to, generation of, or release of classified or sensitive information.
1.4 Assurance Objectives and “Trusted” Systems
The assurance objective is especially important in the present context. That objective is concerned with taking steps to ensure that the security policy is correctly implemented and that the TCB accurately mediates and enforces the intent of that policy. Steps may be taken to insure that each portion of the TCB is assured. To accomplish this objective, two types of assurance are needed.
The first type of assurance is life-cycle assurance. This type of assurance refers to steps taken to ensure that the computer system is designed, developed, and maintained using formalized and rigorous control standards.
The second type of assurance is operational assurance. Operational assurance deals with the features and system architecture used to ensure that the security policy is uncircumventably enforced during system operation. All of the software (sometimes referred to informally in the art as “code”) in the TCB is generally analyzed to determine the assurance level of the system.
As the amount of code in the TCB increases, it becomes more difficult to ensure that the TCB accurately enforces the security policy. Because of this, it is desirable to minimize the amount of trusted code, and thus the complexity of the TCB.
A TCB is usually operated with a substantial amount of software, such as text editors and other applications, operating within the security policy of the TCB. Generally, this untrusted software asks the TCB for access to objects when the user or the untrusted software requires them. Thus, the majority of user's requests to the TCB, and the majority of the information that a user obtains from the TCB, are handled through the agency of untrusted software.
This untrusted software, however, is by nature in danger of compromise and vulnerable to bugs. For some types of requests and displays, malicious or malfunctioning untrusted software could compromise the enforcement of the security policy. Generally, TCBs cannot distinguish between requests faithfully made by the untrusted software on command from a user and either requests made by the untrusted software at its own initiative or requests that misrepresent the user's actual command. For example, if commands issued by an authorized user to change certain users' security levels were made through the agency of untrusted software, it would be possible for malicious or malfunctioning untrusted software to inappropriately raise the security level of a user. Such inappropriate raising of a security level could result in the disclosure of sensitive information.
Furthermore, TCBs generally cannot ensure that displays made by untrusted software are faithful. This poses problems in that if displays of audit records were made through the use of untrusted software it would be possible for malicious untrusted software to misrepresent these audit records to hide suspicious activities.
To overcome these problems, prior-art systems have developed a concept known as a “trusted path.” A trusted path is a mechanism by which the user can communicate directly with the TCB. A trusted path may only be activated by the user or the TCB and cannot be imitated by untrusted code. Such a trusted path is a positive TCB-to-user connection that bypasses all untrusted software. The Orange Book requires a trusted path for all systems to have a security rank of B2 or above.
A “trusted command” (also known as a trusted-path command) is a command which requires a trusted path between the user and the TCB for execution. The specific security policy of a computer system will determine which commands are defined as trusted commands. For example, commands relating to changes of the security levels of users would be trusted commands.
1.5 Parsers as Increasers of System Complexity
Because of perceived performance problems, prior-art computer systems often included code to implement certain functions in the TCB. One such function comprises a portion of code known as the “parser.”
The parser performs the basic interpretation of user commands by translating a human-readable representation of a user command (e.g., a command typed by a user at a keyboard) into a machine-readable representation known as the binary representation, or the parsed command. A user command may consist of a group of words, typed by the user, specifying some action to be taken. The user command may also specify one or more variations or options of that action.
For the convenience of the user, most parsers allow these option words to be typed in any order without changing the meaning of the user command. Also, most parsers allow the user to type the words in either full or abbreviated form. In some instances, several possible abbreviations exist. Further, in most parsers, the user may vary the spacing between the words without changing the meaning of the command. Some parsers also check user commands for proper syntax, and report errors to the user prior to execution of the command. Other parsers prompt the user for missing information, avoiding the need to completely retype an incomplete command.
Thus, several different inputted human-readable representations may be associated with each unique parsed command. It is the job of the parser to translate accurately these inputted representations of user commands (which may vary with each user) into specific parsed command representations. Due to the complex nature of parsing, large amounts of computer code are generally associated with this activity.
Prior-art trusted software systems have included the parser for trusted commands, and thus the associated code, within the TCB. In these systems every trusted command was parsed and executed exclusively by trusted code. The inclusion of the parsing code in the TCB was regarded as necessary for proper system operation.
As discussed above, however, the ease and degree of assuring a system is roughly inversely proportional to the complexity of the system's TCB. Thus, the inclusion of the parser in the TCB results in more complex assurance analysis and a corresponding decrease in system confidence. Prior art devices (since they needed to be small and simple to support assurance) have thereby inherently constrained the user-friendliness of computer systems.